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A METHOD AND SYSTEM FOR LIGHT PATH MONITORING 
IN AN OPTICAL COMMUNICATION NETWORK 

Related Application 

5 [0001] This application claims priority from U.S. Provisional Patent Application 
Serial No. 60/431,725 to Seddigh, N., et al, entitled "Method and Apparatus for 
Tracing Optical Lightpath Via Command Line Interface" and filed on 9 December, 
2002. 

10 Field of Invention 

[0002] This invention relates to optical communication systems and in 
particular to a method and system for monitoring a light path between a source and 
a destination node in an Optical Communication Network (OCN), e.g., for the 
purpose of detecting connectivity problems. 

15 

Background of Invention 

[0003] In order to cost effectively manage OCNs, service providers need 
trouble-shooting and maintenance tools with visibility at the granularity of individual 
light paths or wavelengths. Due to the complexity of the optical layer sophisticated 

20 optical monitoring was a challenge in OCNs. Hence the need for improved Optical- 
layer Performance Monitoring (OPM) has been acknowledged, followed by the 
development of several commercial solutions. While most of these solutions focus 
on detailed spectral analysis, providing high-resolution wavelength, power and signal 
to noise ratio measurements, they do not provide any information about the course a 

25 particular light path has taken through the network. Network operators spend an 
inordinate amount of time troubleshooting connectivity problems in their networks. 
Internet Protocol (IP) networks have extremely useful tools such as IP Traceroute or 
Link-State Packet (LSP) Traceroute to assist the network operator. IP Traceroute, 
for example, is a standard tool, on which many network operators rely. Leveraging a 

30 known paradigm is easy to use, explain and demonstrate. 
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[0004] Canadian Patent Application Serial No. 2,298,848 to Robinson, Marc 
C, et al, filed on 15 February 2002 and entitled "Routes and Path Management", 
and corresponding U.S. Patent No. 6,570,867 issued on 27 May 2003 and also 
entitled "Routes and Paths Management", describe a cost-effective and efficient 

5 framework for management of telecommunications networks. The invention is 

embodied in a route and path management system that contains a data collector unit 
for collecting data from individual network elements, a server for processing the 
collected data into manageable route and path objects and a graphical user interface 
for a user to manage or monitor routes in an IP network. Most of the prior art, 

10 including the above-mentioned patent application, concerns tracing of routes at the 
IP level and does not address optical light path tracing. Some of these capabilities 
are available from Network Management Systems (NMS). Use of a commercial off- 
the-shelf NMS requires the OCN to be compatible with the NMS product. Moreover, 
it may not be possible to provide a network management port at each node in the 

15 OCN because of the increase in cost. 

[0005] Accordingly, there is a need in the industry for the development of 
methods and systems for detecting and monitoring light paths of optical signals 
propagating in optical networks. 

20 

Summary of the Invention 

[0006] Therefore there is an objective of the invention to provide a method 
and system for detecting and monitoring a light path between a source and a 
destination node in an OCN which will not require NMS interaction or any optical to 
25 electrical signal conversion. 

[0007] The present invention relates to a Command Line Interface (CLI) 
based method and system (i.e., not based on any centralized global knowledge) for 
tracing the nodes traversed by an optical light path between a source node and a 
30 destination node in an OCN. 
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[0008] According to one aspect of the invention there is provided a method for 
monitoring a light path between a source node and a destination node in an Optical 
Communication Network (OCN) using a Command Line Interface (CLI), the method 
comprising the steps of executing a procedure called Trace for tracing an existing 
5 light path between the source node and the destination node in the OCN; executing 
a procedure called Walk for identifying a potential light path between the source 
node and the destination node in the OCN, and executing a procedure called Global 
Discovery for identifying the nodes that are traversed by the light path existing 
between the source node and the destination node in the OCN, executing a 

10 procedure called Local Discovery for identifying the nodes that are traversed by the 
light path existing between the source node and the destination node in the OCN, 
wherein the light path to be monitored includes a start node where monitoring is 
invoked through the CLI. The step of executing the procedure called Trace 
comprises the steps of constructing lists of nodes that are on the light path to be 

15 monitored, and displaying said lists of nodes. The step of constructing the lists of 
nodes, comprises the steps of constructing a list of nodes that are traversed in 
sequence by the light path from the start node to the source node as 
RESULTJJST1 , and constructing the list of nodes that are traversed in sequence by 
the light path from the start node to the destination node as RESULTJJST2. The 

20 step of constructing RESULTJJST1 comprises the step of identifying all nodes pre- 
provisioned to be on the light path that have detected and processed a wavekey 
corresponding to the light path wherein the wavekey is a signature that uniquely 
identifies the light path. The step of constructing RESULT_LIST2, comprises the 
step of identifying all nodes pre-provisioned to be on the light path that have 

25 detected and processed the wavekey corresponding to the light path wherein the 
wavekey is a signature that uniquely identifies a light path. The step of displaying 
list of nodes comprises the step of displaying RESULTJJST1 and RESULTJJST2. 

[0009] The procedure called Walk comprises the steps of constructing lists of 
30 nodes that are provisioned with expected wavekey to be present on the light path to 
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be monitored, and displaying said lists of nodes. The step of constructing lists of 
nodes that are provisioned with expected wavekey to be present on the lightpath to 
be monitored comprises the steps of constructing the list of nodes that are 
provisioned to be present with expected wavekey on the light path from the start 
5 node to the source node as RESULTJJST1 , and constructing the list of nodes that 
are provisioned to be present on the light path from the start node to the destination 
node as RESULTJJST2. The step of constructing RESULTJJST1 comprises the 
step of identifying nodes that are provisioned to process the expected wavekey 
corresponding to the light path, wherein the wavekey is a signature that uniquely 
10 identifies the light path. The step of constructing RESULTJJST2 comprises the 
step of identifying nodes that are provisioned to process the expected wavekey 
corresponding to the light path, wherein the wavekey is a signature that uniquely 
identifies the light path. The step of displaying the lists of nodes comprises the step 
of displaying RESULTJJST1 and RESULT JJST2. 

15 

[0010] The procedure called Global Discovery comprises the steps of flooding 
the OCN; and displaying a list of nodes traversed by the light path. The step of 
flooding the OCN comprises the steps of retrieving the list of all optical nodes in the 
OCN from the CN (Control Network) topology information and sending messages to 
20 all the optical nodes enquiring whether they have processed the wavekey 

corresponding to the light path and requesting all the nodes that have detected the 
wavekey to reply back to the start node with an affirmative acknowledgement. 

[0011] The procedure called Local Discovery comprises the steps of 
25 constructing lists of optical nodes detected via local neighbour discovery, and 

displaying a list of nodes traversed by the light path. The step of constructing lists of 
optical nodes detected via local neighbour discovery comprises the steps of sending 
messages to all neighbouring nodes discovered via the CN (Control Network) 
topology information enquiring whether they have processed the wavekey 
30 corresponding to the light path and requesting all the nodes that have detected and 
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processed the wavekey to request their neighbouring nodes (discovered via the CN 
topology information) to reply back to the start node if they have processed the 
wavekey. 

5 [0012] According to another aspect of the invention there is provided a 

system for monitoring a light path between a source node and a destination node in 
an Optical Communication Network (OCN) using a Command Line Interface (CLI), 
the system comprises means for executing a procedure called Trace for tracing an 
existing light path between the source node and the destination node in the OCN, 

10 means for executing a procedure called Walk for identifying a potential light path 
between the source node and the destination node in the OCN, and means for 
executing a procedure called Global Discovery for identifying the nodes that are 
traversed by the light path existing between the source node and the destination 
node in the OCN means for executing a procedure called Local Discovery for 

15 identifying the nodes that are traversed by the light path existing between the source 
node and the destination node in the OCN, wherein the light path to be monitored 
includes a start node where monitoring is invoked through the CLI. The means for 
executing the procedure called Trace comprises means for constructing lists of 
nodes that are on the light path to be monitored and means for displaying said lists 

20 of nodes. The means for constructing the lists of nodes comprises means for 

constructing a list of nodes that are traversed in sequence by the light path from the 
start node to the source node, as RESULTJJST1 and means for constructing the 
list of nodes that are traversed in sequence by the light path from the start node to 
the destination node, as RESULTJJST2. The means for constructing 

25 RESULT_LIST1 comprises means for identifying all nodes that have processed a 
wavekey corresponding to the light path, wherein the wavekey is a signature that 
uniquely identifies the light path. The step of constructing RESULTJJST2 
comprises means for identifying all nodes that have used the wavekey 
corresponding to the light path, wherein the wavekey is a signature that uniquely 

30 identifies a light path. The means for displaying the list of nodes comprises means 
for displaying RESULT JJST1 and RESULT JJST2. 
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[0013] The means for executing the procedure called Walk comprises means 
for constructing lists of nodes that are provisioned with expected wavekey to be 
present on the light path to be monitored and means for displaying said lists of 

5 nodes. The means for constructing lists of nodes that are provisioned with expected 
wavekey to be present on the light path to be monitored comprises means for 
constructing the list of nodes that are provisioned with expected wavekey to be 
present on the light path from the start node to the source node as RESULTJJST1 , 
and means for constructing the list of nodes that are provisioned with expected wave 

10 key to be present on the light path from the start node to the destination node as 
RESULTJJST2. The means for constructing RESULTJJST1 comprises means for 
identifying nodes that are provisioned with expected wavekey to process the 
wavekey corresponding to the light path, wherein the wavekey is a signature that 
uniquely identifies the light path. The means for constructing RESULTJJST2 

15 comprises means for identifying nodes that are provisioned with expected wavekey 
to process the wavekey corresponding to the light path, wherein the wavekey is a 
signature that uniquely identifies the light path. 

[0014] The means for executing the procedure called Global Discovery 
20 comprises means for flooding the OCN, and means for displaying a list of nodes 

traversed by the light path. The means for flooding of the OCN comprises means for 
retrieving the list of all optical nodes in the OCN from the CN (Control Network) 
topology information and means for sending messages to all the optical nodes 
enquiring whether they have processed the wavekey corresponding to the light path 
25 and means for requesting all the nodes that have detected the wavekey to reply 
back to the start node with an affirmative acknowledgement 

[0015] The means for executing the procedure called Local Discovery comprises 
means for constructing lists of optical nodes detected via local neighbour discovery 
30 and means for displaying a list of nodes traversed by the light path. The means for 
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constructing lists of optical nodes detected via local neighbour discovery comprises 
means for sending messages to all neighbouring nodes discovered via the CN 
(Control Network) topology enquiring whether they have detected and processed the 
wavekey corresponding to the light path, and means for requesting all the nodes that 
5 have detected and processed the wavekey to request their neighbouring nodes 
(discovered via the CN topology information) to reply back to the start node if they 
have processed the wavekey. 

[0016] Thus, the method and system of the embodiments of the invention 
10 provides a tool for optical light path tracing that does not use a NMS, but determines 
the nodes that a light path is traversing through a CLI. The invention deploys 
Tropic's Wavelength Tracker technology as described in detail in the following three 
patent applications and one patent, incorporated herein by reference: 

(1 ) TR-041 (OBEDA) U.S. Patent Application Serial No.09/963,501 to Obeda, 
15 P.D., et al, entitled 'Topology Discovery in Optical WDM Networks", filed on 27 

September 2001; 

(2) TR-074 (CIP#2) (WAN) U.S. Patent Application Serial No. 10/263,959 to 
Wan, P.W., et al, entitled "Channel Identification in Communications Networks", filed 
on 4 October 2002; 

20 (3) TFM 19-CIP (OBEDA) U.S. Patent Application Serial No. 10/452,51 1 to 
Obeda, P.D., et al, entitled "Method and System for Identification of Channels in an 
Optical Network", filed on 3 June 2003; and 

(4) TR-075 (JIN) U.S. Patent No. 6,597,161 to Jin, D., et all, entitled "Method 
and Apparatus for Spectrum Analysis With Variable Detection Latency and Multiple 
25 Layer coherent Integrations", which issued on 22 July 2003, 

which technology is used in conjunction with Transmission Control Protocol / User 
Datagram Protocol (TCP/UDP) messaging and a neighbor discovery technique for 
tracing the end-to-end light path. The main advantage of this tool is that it does not 
use a specific NMS but can be executed from a CLI on any node of the light path. 
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Brief Description of the Drawings 

[0017] Further features and advantages of the invention will be apparent from 
the following description of the embodiment, which is described by way of example 
only and with reference to the accompanying drawings, in which: 
5 [0018] Figure 1 presents a system that illustrates the relationship between an 
OCN and its associated Control Network (CN); 

[0019] Figure 2 shows an example of OCN; 

[0020] Figure 3 presents an example of OCN with mis-fibering; 

[0021] Figure 4 presents a flowchart that illustrates the steps of the procedure 
10 Trace of the method for lightpath monitoring according to the embodiment of the 
invention; 

[0022] Figure 5 presents a flowchart explaining the steps of the procedure 
Trace of Figure 4 in more detail; 

[0023] Figure 6 presents a flowchart that illustrates steps of the procedure 
15 Global Discovery of the method for lightpath monitoring according to the 
embodiment of the invention; and 

[0024] Figure 7 presents a flowchart that illustrates steps of the procedure 
Local Discovery of the method for light path monitoring according to the embodiment 
of the invention. 

20 

Detailed Description of the Invention 

[0025] A method for light path monitoring in an optical network will be 
described with respect to an OCN 100 and its associated CN presented in Figure 1 
as an example. The system has three nodes: node A 102, node B 104, and node C 

25 106. CN is an IP network used for exchanging control messages among optical 
nodes. Each of the nodes in this example is equipped with respective network 
management ports 122, 124, and 126. A node may be connected to the CN that is 
an IP network through a network management port. In this example, node A and B 
are connected to the CN (see Figure 1 ). Each node A, B, and C is equipped with 

30 Band Optical Filter Linecards (BOFs) 110, 116, 118 and 120 respectively for 

8 
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handling the optical signal. The BOF 1 10 in node A is connected to the BOF 1 16 in 
node B. BOF 118 in node B is connected to BOF 120 in node C. Note that control 
messages are routed from one node to another using both the CN as well as Optical 
Supervisory Channels (OSC) in the OCN. Nodes A and B in this example are 
equipped with OSC cards 1 12 and 1 14 respectively. Every node in the optical 
network has a connection to the CN (either directly or via other nodes). By retrieving 
the CN topology information, one optical node can learn about the existence of all 
other optical nodes in the OCN. Adjacency information for nodes on the CN is 
available to the system. If OSC cards are used between 2 nodes, this adjacency will 
appear in the CN topology. In such configurations, the CN adjacency information 
can be used to reflect optical node adjacency connectivity - this information will be 
automatically available to nodes. In cases where the OSC cards are not used 
(between Node B and Node C), the adjacency between these two nodes is to be 
statically provisioned at each node. Each node is given the neighbour's router 
identification (Router ID). 

[0026] Monitoring a light path for identifying connectivity problems is achieved 
by exchanging inter-node messages using both the CN and the OSCs in the OCN. 
Such connectivity problems include the existence of failure points in a light path, 
20 mis-fibering as well using incorrect provisioning information at nodes. The light path 
to be monitored can be identified using Wavelength Tracker technology. The 
Wavelength Tracker technology applies a unique optical signature to each 
wavelength at the DWDM layer. The signature allows the system to distinguish 
between multiple instances of the same colour traveling through the network. 

25 

[0027] The unique signature is conceptually equivalent to an identification tag 
or label commonly used by MPLS (Multi-Protocol Label Switch) paths in an IP 
network. The optical signature (also called a WaveKey) is applied to the optical 
signal at the source node of the light path. The optical signature is detectable at 
30 intermediate nodes on the light path via inexpensive decoders present on line cards. 

9 
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Detection of the optical signature is accomplished without an OEO (Optical- 
Electrical-Optical) conversion at intermediate nodes, thus resulting in a cost-effective 
solution. Wavelength Tracker technology is used for a variety of applications 
including optical power monitoring and loss of light avoidance. This invention 
5 describes the use of Wavelength Tracker as part of a CLI-based system to achieve 
the tracing and fault detection of light paths. The technology for generating a 
wavekey has been described in three U.S. patent applications and one U.S. patent, 
listed in Paragraph No. 16 above, and incorporated herein by reference. 

10 [0028] The method for monitoring a light path of a signal in the optical network 
of the embodiment of the invention includes four procedures: Trace, Walk, Global 
Discovery and Local Discovery for identifying connectivity problems. These 
procedures do not require any Network Management System (NMS) interaction. 
Trace (Light path Trace), Walk, Global Discovery and Local Discovery can be 

15 invoked from a Command Line Interface (CLI). A brief description of each of these 
procedures is provided next. 

[0029] The procedure called Trace is used to verify the sequence of nodes 
expected to be traversed by a specific light path - it can be used to detect mis- 

20 configuration problems. In traversing the light path, nodes are communicated in 
sequence and asked whether they have detected the wavekey specific to the light 
path being traced. The expected downstream (or upstream) node in the light path is 
discovered via provisioning information on the node currently being visited. 
Although it is typically executed from the head (source) node of the light path, the 

25 command for the Trace procedure can be executed from any node along the light 
path. The result of the procedure is to display the list of nodes traversed from the 
start node to the destination node of the light path as well as the list of nodes 
traversed from the source node to the start node. For example, an OCN in Figure 2 
has nodes A, B, C, D, and E that are connected by a fiber (shown by the dashed line 

30 202). The solid line 204 through these nodes displays a light path. If the command 



10 



Attorney Docket No. TR-176-US 



for tracing a light path identified by a given wavekey is executed at start node C, two 
lists, RESULTJJST1 {C-B-A} and RESULT JJST2 {C-D-E} will be displayed. 
RESULTJJST1 contains the sequence of nodes along the light path in the receive 
direction (upstream) from the start node. RESULTJJST2 contains the sequence of 

5 nodes along the light path in the transmit direction from the start node (downstream). 
If the start node is the source node for the light path A, RESULTJJST1 is {A-B-C-D- 
E} where as RESULTJJST2 is empty. Figure 3 displays an example of mis-fibering. 
Nodes A, B, C, D and F are connected by a fiber (shown by a dashed line 302) 
whereas the provisioned light path is expected to traverse nodes A, B, C, D, and E 

10 (shown by a solid line 304). For a start node of A in Figure 3, RESULTJJST1 is 
given by {A-B-C-D} while RESULTJJST2 is empty. Note that since D is mis-fibered 
to F, RESULT_LIST1 terminates at D. 



[0030] The procedure Walk is similar to Trace except that it is used primarily 
15 before setting up a light path for knowing the sequence of nodes that will be 
traversed if the light path identified by a given wavekey is set up. Since the light 
path is yet to be set up, network provisioning information at the nodes is used for 
generating RESULT JJST1 and RESULTJJST2. Invoking Walk at node C and 
node A in Figure 2 will produce the exact same result as obtained with Trace. 
20 However, with a start node of A in Figure 3, a RESULTJJST1 of {A-B-C-D-E} and 
an empty RESULTJJST2 is obtained. Note that in comparison to the 
RESULTJLIST1 obtained with Trace, an additional node E is displayed in case of 
Walk. This is because Walk uses the static provisioning information only that 
indicates that E is the neighbour of node D for the given light path with the expected 
25 wavekey. In reality, however, when light path is set up, the light path will extend 
from D to F due to the mis-fibering of D to F. 



[0031] The procedure Global Discovery is used to determine all the nodes 
that a given light path visits in a network. The list of nodes produced is not 
30 necessarily ordered in the same sequence of nodes the light path traverses from its 
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source to its destination. Global Discovery is useful as a complement to Trace in 
trouble-shooting cases of mis-fibering or adding/dropping channels to the wrong 
port. It is especially useful when the mis-fibering is not to a known neighbour node. 
Invocation of procedure Global Discovery at start node A in the system in Figure 2 
5 could produce a number of results including {A,D,C,B,E} or {A,B,C,D,E} or 

{A,B.D,C,E}. Invoking Global Discovery at start node A in Figure 3 could produce a 
number of results including {A,B,C,D,F} or {A,C,F,D,B} or {A,F,D,B,C}. 

[0032] The procedure Local Discovery is useful in cases of mis-fibering. Not 
10 only does it detect mis-fibering has occurred, it may be able to indicate which node 
the mis-fibering terminates on. However, it can only be used if nodes use an OSC 
card to connect to every other node with which they have a regular optical link. 
Local Discovery identifies the actual path traversed by a light path including 
unexpected nodes. It is less invasive than Global Discovery as it does not need to 
15 contact every single node in the network. Local Discovery produces a list of nodes 
that belong to a given light path. Though in most cases, the displayed order of 
nodes will represent the sequence of nodes a light path traverses, there are some 
cases where the order of nodes in the list does not need to follow any sequence as 
in the case of Trace or Walk. Invocation of procedure Local Discovery at start node 
20 A in the system in Figure 2 will produce a result of {A, B, C, D, E} or {A,E,D,C,B}. 
Invoking Discovery at start node C results in the list {C, D, E, B, A}. Invoking Local 
Discovery at start node A in Figure 3 will result in the list {A, B, C, D, F} which is the 
exact sequence of nodes traversed by the light path. 

25 [0033] The operations of the procedure Trace are explained with the help of 
the flow charts 400 and 500 presented in Figures 4 and 5 respectively. Upon start 
(box 402 in Figure 4) procedure Trace constructs RESULT_LIST1 (box 404) and 
RESULT JJST2 (box 406). RESULTJJST1 contains the sequence of nodes 
traversed by the light path in the receive direction (upstream) from start node 

30 whereas RESULTJJST2 contains the sequence of nodes in the transmit direction 
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(downstream) from start node. Note that there are two special cases. In the first, the 
start node is the source node for the light path. Since there is no other node in the 
receive direction RESULTJJST1 is empty. In the second, the start node is the 
destination node for the light path. Since there is no other node in the transmit 
5 direction RESULTJJST2 is empty. After computing RESULTJJSTI and 

RESULTJJST2 the two lists are printed (box 408) and the procedure terminates 
(box 410). 

[0034] The detailed operations of procedure Construct (i), i = 1 ,2 in the above 

10 example, that is used in the generation of RESULTJJST1 and RESULTJJST2 
(Figure 4) are explained with the help of procedure 500 of Figure 5. Upon start (box 
502), the procedure 500 creates an initial empty list called RESULTJJSTi (box 504). 
If the argument T passed to the procedure is 1, the procedure exits "YES" from box 
506 and sets the value of N to the provisioned neighbouring node (for this light path) 

15 of start node in the receive direction (box 508). Otherwise the procedure exits "NO" 
from box 506 and sets the value of N to the provisioned neighbouring node (for this 
light path) of start node in the transmit direction (box 510). A message is then sent 
to N enquiring whether it has detected the wavekey corresponding to the light path 
whose path is being traced (box 512). The procedure checks whether the response 

20 from N has arrived and exits "YES" from box 514 upon reception of the reply. 

Otherwise, it exits "NO" from box 514 and goes back to the top of the loop 513 and 
checks for the arrival of the response. The neighbouring node responds with an 
acknowledgement (ACK) if it has detected the specified wavekey indicating that it is 
on the light path being monitored. If the provisioning information at N indicates a 

25 subsequent provisioned node (M) on the same light path, the identification of this 
neighbouring node is included in the response. On the reception of an ACK, the 
procedure exits "YES" from box 516 and adds N to RESULTJJSTi. When N is an 
end node (start or destination node for the light path) no neighbouring node 
information is included in the response, and the procedure exits "NO" from box 520 

30 and terminates (box 524). Otherwise, N is set to M - the neighbouring node returned 
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with the response (box 522) and the procedure loops back to the entry of box 512 
designated with reference numeral 51 1. The reception of a negative response in 
box 516 indicates that the currently polled node N, is not on the light path, and the 
procedure exits "NO" (from the box 516) and terminates (box 524). 

5 

[0035] The steps of procedure Walk are similar to those of procedure Trace. 
The only difference lies in the processing of the enquiry message sent by start node. 
The enquiry message indicates the expected wavekey. The receiving node does not 
check whether or not the wavekey is in use indicating its participation in a currently 
10 active light path. Since Walk is concerned with a potential light path to be set up in 
the future, the provisioning information stored in the node is used. A node responds 
with an ACK if the provisioning information indicates that the expected wavekey as 
indicated in the query is present, otherwise it sends a negative response. 

15 [0036] The operations of procedure Global Discovery are explained with the 
help of flowchart 600 of Figure 6. A concept called flooding of the OCN is used by 
this procedure. Upon start (box 602) the procedure retrieves the list of optical nodes 
in the OCN (box 604 in Figure 6). The list of nodes is extracted by examining the 
CN topology information, which is readily available to every optical node. The 

20 procedure then sends an enquiry message to each of the nodes detected in step 
604 asking whether the nodes have observed or detected the wavekey 
corresponding to the light path of interest. The procedure then enters box 608 
where it awaits responses from all the optical nodes. Received responses from the 
optical nodes are processed in box 610. If the response from the optical node 

25 indicates "YES" confirming the detection of the specified wavekey, the node is 

added to the list of nodes confirmed to be on this lightpath (box 612). The procedure 
then moves to box 614 via 613. If the response indicates "NO", the procedure 
directly moves to box 614 where there is a check to determine if there are any 
responses outstanding. If not all optical nodes have responded (box 614), then the 

30 procedure returns to box 608 where it awaits future responses. Otherwise, if the 
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outcome of box 614 is "NO", it is assumed that all optical nodes have responded. In 
this case, the final result is displayed in the form of all the optical nodes which have 
detected the wavekey and which are considered to be on the deployed light path. 
The procedure terminates in box 618. 

5 

[0037] The operations of procedure Local Discovery are explained with the 
help of flowchart 700 of Figure 7. This procedure is applicable in the cases where 
there is at least one OSC card-pair connecting optical nodes that have fibre 
connections between them. Upon start (box 702) the procedure 700 executing at 

10 the start node sends messages to all its neighbouring nodes discovered via the 
available CN topology information, enquiring whether they have detected the 
wavekey corresponding to the light path (box 704). The procedure waits until a 
response arrives (box 706). Upon arrival of the response, the procedure exits "YES" 
from box 706 and checks the nature of the response. If the response is an 

15 acknowledgement (ACK), it exits "YES" from box 708 and adds the node sending 
the ACK to a list named RESULT that is initially empty (box 710). An ACK from a 
neighbouring node implies that the node has detected the specified wavekey, thus 
indicating that it is on the light path. The procedure sends a request to this 
neighbour to send an enquiry message to all its neighbours (that it discovers via the 

20 available CN topology information) in turn asking whether they have detected the 
specified wavekey (box 712). The neighbour's neighbours are to send their 
responses back to this start node on which the procedure (box 700) was invoked. 
The procedure enters a waiting phase checking for replies from other nodes (box 
716) or the occurrence of a timeout (box 714). A node responds to an enquiry 

25 message only if it has detected the wavekey and has not responded to the start 

node earlier. With the reception of a response the procedure loops back to the entry 
of box 708 to check the nature of the response. If a time out occurs, it means that 
there are no more nodes left on the light path to respond to the start node and the 
procedure terminates (box 718). In case the response checked in box 708 is not an 
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ACK, it will exit "NO" from Box 708 and the procedure goes to the entry of box 714 
waiting for the occurrence of another response or the timeout. 

[0038] An advantage of the method is that it does not require any NMS 
5 interaction and can be invoked at any node on a light path through a CLI. 

[0039] Thus, a method and a system for monitoring a light path between a 
source and a destination node in an Optical Communication Network (OCN) are 
provided. 

10 

[0040] The processing described above may be performed by a general- 
purpose computing engine alone or in connection with a special purpose computer. 
Such processing may be performed by a single platform or by a distributed 
processing platform. In addition, such processing and functionality can be 

15 implemented in the form of special purpose hardware or in the form of software 
being run on a general-purpose computing platform. The procedures associated 
with the present embodiments may be stored in any storage device, such as for 
example, non-volatile memory, an optical disk, magnetic tape, or magnetic disk. 
Furthermore, the processes may be programmed when the sysiem is manufactured 

20 or via a computer-readable medium at a later date. Any data handled in such 

processing or created as a result of such processing can be stored in any memory 
as is conventional in the art. By way of example, such data may be stored in 
temporary memory, such as in the RAM of a given computer system or subsystem. 

25 [0041] Numerous modifications and variations of the present invention are 
possible in light of the above teachings. For example, instead of using a timeout in 
the Discovery procedure, each responding node can include the number of its 
neighbors. After receiving this number, start node can wait for the designated 
number of responses and the timeout is not necessary. Also, instead of responding 

30 nodes contacting their neighbours, they can provide the list of neighbours to the start 
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node. The start node can then be responsible for contacting all the specified 
neighbours. 

[0042] It is therefore to be understood that within the scope of the appended 
5 claims, the invention may be practiced otherwise than as specifically described 
herein. 
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